Add the rite_calendar_test object type to the LiturgicalCalendar model - #31

What broke

LiturgicalCalendarAPI #785 introduced a new OpenFGA object type, rite_calendar_test, and started querying it from ResourceAdminService::VIEWER_OBJECT_TYPES and TEST_OBJECT_TYPES. It generalises general_roman_calendar_test, whose single fixed id (general_roman_calendar) could only ever name the Roman rite-level calendar; the new type's object id is the bare rite, so rite_calendar_test:roman succeeds it and rite_calendar_test:ambrosian is the scope the generalisation exists for.

The type was never added to the deployed model. #785 edited LiturgicalCalendarAPI/scripts/openfga-model.additive.json — a file that repo's own runbook (docs/ops/rbac-create-governance-runbook.md, lines 16-19) already declares dead:

the OpenFGA model now lives in cdcf-infra (auth/models/LiturgicalCalendar.json) […] Model changes go through a PR in cdcf-infra, followed by an operator running ./setup-openfga.sh --target production --create-litcal-store

No such PR was ever opened. This is it. (That dead file is being deleted in a companion PR on the API side, since looking like a live surface is exactly how this happened.)

Observable symptom — global, not scoped

listObjects on an unknown type returns 400 type_not_found, which the API's OpenFgaClient surfaces as a RuntimeException. In ResourceAdminService the foreach over object types sits inside a single try, and the catch (\RuntimeException) returns array_fill_keys(VIEWER_OBJECT_TYPES, []) — so one unknown type empties every type's scope list, for every user. Dashboard card gating therefore collapses globally, not just for rite-scoped tests.

Confirmed against a dev store: its latest model contains user, wider_region, national_calendar, diocesan_calendar, general_roman_calendar, national_calendar_test, diocesan_calendar_test, general_roman_calendar_test — and no rite_calendar_test.

Downstream LiturgicalCalendarFrontend e2e specs this unblocks:

• rbac/07-dashboard-card-scoping:143
• rbac/12
• rbac/13:153 and rbac/13:201
• rbac/15-dashboard-tests-card-matrix:36

The change

rite_calendar_test with relations admin / editor / viewer, identical to general_roman_calendar_test: editor is a union including admin, viewer a union including both, each directly relatable to user.

That relation set is not a guess. It is:

• what the API actually queries — listObjects for viewer, editor and admin (ResourceAdminService), and OpenFgaAuthorizationMiddleware checking admin for PUT/DELETE and editor for PATCH;
• what LiturgicalCalendarAPI/docs/ops/test-scope-migration-runbook.md Step 1 specifies — "added […] alongside general_roman_calendar_test, with an identical relation set";
• consistent with the sibling national_calendar_test / diocesan_calendar_test types already in this file.

No deleter. The consumer's own expectations file forbids that relation model-wide ("forbidden_relations": {"*": ["deleter"]}), and the dead file's copy of the type carries one — one more reason not to have mirrored it verbatim.

Purely additive. general_roman_calendar_test is untouched: pre-migration tuples on it must keep authorizing until scripts/migrate-rite-test-tuples.php --apply --prune has run in every environment, and the API still accepts the old type everywhere.

auth/handoffs/liturgicalcalendar.md gets a note rather than an edited type list — the list there describes deployed model 01KW4FW2ZCT1E693PY8D9TJEFM, which genuinely does not contain this type yet.

Verification

Not by inspection — against the consumer contract itself, using the registry entry from #30:

# main's model
✗ [LiturgicalCalendarAPI] required_types: type "rite_calendar_test" not found in model   (exit 1)

# this branch's model
✓ No violations. LiturgicalCalendar satisfies LiturgicalCalendarAPI's expectations.      (exit 0)

./auth/validate-expectations.selftest.sh — all 21 cases behave as declared.

Coordination with #30

#30 should not merge before this PR. auth/models/consumers.json on main is still [], so validate-models on this PR passes trivially (empty registry = nothing to contradict) — its green tells you nothing, hence the manual run above. #30 registers LiturgicalCalendarAPI against development's expectations file, which already lists rite_calendar_test in required_types. #30's own CI ran on 2026-08-05, before that line existed; re-run today it goes red, and merging it first turns main red on the push-triggered run. Landing this first makes #30 green again with no change to #30 itself.

Deploy step required — this PR alone changes nothing live

Merging only updates the model file. An operator must then, per auth/README.md:

cd /opt/cdcf-auth/auth
./setup-openfga.sh --target production --create-litcal-store

The lock guard will refuse (exit 7) if the store's latest model does not match LiturgicalCalendar.lock.json; otherwise it uploads and prints the new model ID plus the lock JSON to commit. That lock update is a follow-up PR — this one deliberately leaves LiturgicalCalendar.lock.json alone, since the script never writes it and the ID is not knowable before the upload. Any consumer pinning OPENFGA_MODEL_ID needs the new ID too, and the liturgicalcalendar.md handoff note should be resolved at the same time.

Local dev stacks (including the frontend e2e store) pick the type up by re-running setup-openfga.sh --target local against a clone of this repo after merge — the e2e specs above stay red until that happens.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added a test liturgical calendar access type with administrator, editor, and viewer roles.
  • Editors inherit administrator permissions, while viewers inherit editor and administrator access.
  • All roles support direct user assignments.

• Documentation

  • Documented the type’s relationships, object ID format, deployment steps, and required follow-up configuration updates.